QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930065.txt

Internet Message Format | 1994-06-04 | 24KB

Date: Tue,  9 Mar 93 04:30:07 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #65
To: tcp-group-digest


TCP-Group Digest            Tue,  9 Mar 93       Volume 93 : Issue   65

Today's Topics:
                     ampraddr robot help (2 msgs)
                  any lower version of nos (3 msgs)
                           Baycom USCC card
              HELP: NOS/JNOS Shared Interrups. (2 msgs)
                   HELP: NOS/JNOS Shared Interrupts
                 hidden transmitter routing (2 msgs)
                         TCP Window (2 msgs)

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 8 Mar 93 14:23:34 EST
From: John Ackermann   AG9V <[e-mail]>
Subject: ampraddr robot help
To: tcp mailing list <[e-mail]>

How do I tell the ampraddr robot how to delete an mx record?  I have two
old entries stuck in the database as follows:

ag9v IN MX 10 schizo.samsung.com.
ag9v IN MX 20 schizo.samsung.com.

I've tried a couple of times to post a partial mx record, missing either
the exchanger or the preference, but the robot bombs with an error.

Is there any way to delete these guys via the robot?

Thanks...

John

------------------------------

Date: Mon, 08 Mar 93 22:49:56 MST
From: Lyndon Nerenberg <[e-mail]>
Subject: ampraddr robot help
To: "John R. Ackermann" <[e-mail]>  John Ackermann      AG9V <[e-mail]>

Try this ...
ag9v in mx 10 delete

------------------------------

Date: Mon, 8 Mar 93 9:39:21 MST
From: [e-mail] (Josh Steinhurst)
Subject: any lower version of nos
To: [e-mail]

I am sorry if this is the wrong place for this message, but it seems the
closest. My question is, is thier any version of tcp/ip(for radio) that
works at a lower level then nos. This would allow you to use normal
individual tcp/ip programs (Such as nntp, and other things) over a radio
link, that nos doesn't emulate.

Once again I am sorry if this is dumb question (I don't yet have any
packet setup, but am thinking of seting up packet for tcp/ip as I find
normal AX.25 and TheNet rather boring.) However I do have a bit of
Internet know-how...
--


------------------------------

Date: Mon, 8 Mar 93 13:56:29 MST
From: "Marvin Match" <match@[128.110.44.31]>
Subject: any lower version of nos
To: [e-mail], [e-mail]

On Mon, 8 Mar 93 9:39:21 MST, Josh Steinhurst wrote:

>I am sorry if this is the wrong place for this message, but it seems the
>closest. My question is, is thier any version of tcp/ip(for radio) that
>works at a lower level then nos. This would allow you to use normal
>individual tcp/ip programs (Such as nntp, and other things) over a radio
>link, that nos doesn't emulate.
>
>Once again I am sorry if this is dumb question (I don't yet have any
>packet setup, but am thinking of seting up packet for tcp/ip as I find
>normal AX.25 and TheNet rather boring.) However I do have a bit of
>Internet know-how...
>--

John,

Stop appologizing! I've thought the same things. While I can't give you a
good answer, you might want to look at the TCP-IP code available from
Watterloo University in Canada. Remember that radio has it's own unique
problems, and TCP-IP for a wire doesn't address them. Follow the discussions
on tcp-group@ucsd for awhile and you'll start to understand what some of
them are. A new discussion group is forming on a list-server at Pixar to
discuss the various protocols as they apply (or don't apply) to amateur
radio that you might be interested in. To subscribe send e-mail to:
[e-mail] with a blank subject line and the body of the message
being: subscribe advanced-packet <YOUR-FULL-NAME>

Hope this helps, and I'd be interested in hearing your comments.

Marvin Match

------------------------------

Date: Tue, 9 Mar 93 09:22:50 PST
From: "Jerzy Tarasiuk" <[e-mail]>
Subject: any lower version of nos
To: "Marvin Match" <match@[128.110.44.31]>

> From: [e-mail] (Josh Steinhurst)
> Message-Id: <[e-mail]>
> Date: Mon, 8 Mar 93 9:39:21 MST
> From: "Marvin Match" <match@[128.110.44.31]>
> Date: Mon, 8 Mar 93 13:56:29 MST
> Message-Id: <50190.match@[128.110.44.31]>

I've though similar things, too - the modular NOS requested by Russ
(6 Jul 92, 2a586eb5.crynwr, Subject: A simple, stable, nos, please!).
But my problem is I don't seem wise enough to decide what should be
modules specifications. And even memory model seems to be a problem:
Russ suggested HUGE, this causes very little work to be needed to make
it all working and very little advantages from the modularity.
Someone suggested SMALL: its great advantage is ability to move module
in memory or even swap it to disk (module has no reason to have any
segment address in it), but it causes serious problems with memory
allocation - there is no small-model heap for multitasking or memory
allocation must move about hundred kilobytes, since any memory getten
from malloc() is FAR (and note for easy relocation must not store its
segment address anywhere in module, must store its HANDLE; and must
not access it directly - must use kernel functions instead).
Has anyone any thoughts/ideas/...etc. on this subject ?

Where can get the TCP-IP code from Watterloo University ?  73's, JT

------------------------------

Date: Mon, 8 Mar 93 16:19:10 GMT
From: [e-mail]
Subject: Baycom USCC card
To: [e-mail], [e-mail]

>Has anybody ever used a USCC Baycom 4 port card with NOS???
>I cannot make it work. PLEASE HELP !!!!!!!! I am desperate.

>73 Demetre SV1UY

>E-mail [e-mail]

Yes, one of the hub stations in Hertfordshire (north of London)
is using one successfully with JNOS 108.
It does need modifications to SCC.C (and a minor modification
to SCC.H) in order to work.

I've put the modifications into the code in such a way that
the driver will still work with all the other SCC cards.
Is there general interest in this code (the number of Baycom
USCC 4-port cards around (at least in the UK) can be counted
on the fingers of one foot) ?


Andrew Benham
--------------------------------------------------------------------
[e-mail]   BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
                 [phone]    Fax: [phone]
Home:            [e-mail] [44.131.19.195]    G8FSL@GB3XP
--------------------------------------------------------------------

------------------------------

Date: Mon, 8 Mar 93 14:45:16 GMT
From: Alan Cox <[e-mail]>
Subject: HELP: NOS/JNOS Shared Interrups.
To: aa6ed <@UCSD.EDU:aa6ed@algedi>, [e-mail]

Welcome to the wacky world of PC hardware

The PC bus doesn't support multiple cards on a single interrupt properly.
Multiple ports on a single card require some extra board logic, and normally extra
software knowledge. The cl;aclassic example of this is the AST 4 port clones.
If your card is really really smart just looping through all the ports that
match the interrupt in the asyint() handler will do the trick. For most
cards it will work for a bit and then a port will jam when the timing is just
wrong. You _can_ drive multiple ports on an interrupt without any fancy
hardware support but its very very hard and unpleasant and I know no version
of NOS supporting that or even the AST 4 port additions.

Alan

------------------------------

Date: Mon, 8 Mar 93 13:21:04 PST
From: [e-mail]
Subject: HELP: NOS/JNOS Shared Interrups.
To: [e-mail]

In <[e-mail]> Alan Cox <[e-mail]> writes:
>Welcome to the wacky world of PC hardware
>
>The PC bus doesn't support multiple cards on a single interrupt properly.
>Multiple ports on a single card require some extra board logic, and normally extra
>software knowledge. The cl;aclassic example of this is the AST 4 port clones.
>If your card is really really smart just looping through all the ports that
>match the interrupt in the asyint() handler will do the trick. For most
>cards it will work for a bit and then a port will jam when the timing is just
>wrong. You _can_ drive multiple ports on an interrupt without any fancy
>hardware support but its very very hard and unpleasant and I know no version
>of NOS supporting that or even the AST 4 port additions.
>
>Alan
>

MBBIOS should operate properly with various shared interrupt schemes
if you can use that from NOS.

Roy, AA4RE

------------------------------

Date: Mon, 8 Mar 93 16:04:28 PST
From: Bill Healy <[e-mail]>
Subject: HELP: NOS/JNOS Shared Interrupts
To: [e-mail] (tcp-group)

> Welcome to the wacky world of PC hardware
>
> The PC bus doesn't support multiple cards on a single interrupt properly.
> Multiple ports on a single card require some extra board logic, and normally extra
> software knowledge. The cl;aclassic example of this is the AST 4 port clones.
> If your card is really really smart just looping through all the ports that
> match the interrupt in the asyint() handler will do the trick. For most
> cards it will work for a bit and then a port will jam when the timing is just
> wrong. You _can_ drive multiple ports on an interrupt without any fancy
> hardware support but its very very hard and unpleasant and I know no version
> of NOS supporting that or even the AST 4 port additions.
>
> Alan

Look a little harder if you think no version of NOS supports shared
interrupts. Here's part of a message from Phil from April of last year, I
think the code has since been included in JNOS as well.

Bill N8KHN


> Date: Sat, 11 Apr 92 16:07:06 -0700
> From: [e-mail] (Phil Karn)
> To: [e-mail]
> Subject: src0411.zip now on ucsd.edu
>
> Hi!
>
> Believe it or not, I have been busy recently on the base version of
> NOS. I've just uploaded src0411.zip and net.exe to ucsd.edu, directory
> /hamradio/packet/tcpip/ka9q. There are a LOT of changes in this code,
> mostly below the surface. I'm not able to test everything to make sure
> it all still works, so I would really appreciate it if people could do
> that for me and let me know. In particular, I have not tested the
> netrom, scc, drsi, hs, and arcnet network modules, and they may or may
> not work.
>
> Here are the changes, in no particular order:
>
> 1. Optional IRQ chaining is now supported. If you suffix "C" to the IRQ
> number in an attach command, e.g.,
>
> attach asy 0x1a8 4c slip com2 1024 1500 19200
>
> the com2 driver's interrupt handler will call whatever vector was
> previously installed for IRQ 4 whenever it has finished servicing an
> interrupt. So you can now attach all four ports of an AST 4-port serial
> card in enhanced mode with the following commands:
>
> attach asy 0x1a0 4 slip com1 1024 1500 19200
> attach asy 0x1a8 4c slip com2 1024 1500 19200
> attach asy 0x1b0 4c slip com3 1024 1500 19200
> attach asy 0x1b8 4c slip com4 1024 1500 19200
>
> Note that the first attach command didn't specify the 'c' flag, because
> the pre-existing vector for IRQ4 at that point is the "dummy" IRQ
> handler in the bios, and there's no need to call it. Things will still
> work if the 'c' flag were specified here, but interrupt servicing would
> take a little longer than necessary to call the do-nothing dummy vector
> in the BIOS.
>
> You should also attach your fastest device last, since that will place
> it first on the chain of interrupt handlers to be called.
>
> Note that the IRQ number is now expected to be in DECIMAL, not hex. Not
> that it made much difference, of course, since most IRQ numbers that
> people use are below 10. (This change was necessary, of course, to
> prevent the 'c' flag from confusing the number-conversion routine).
>
> Those writing device drivers should note that this feature required
> changes to the conventions used for interrupt handlers in NOS. In
> particular, each interrupt handler (called from the assembler vector
> hook) is expected to return the previous interrupt vector found at the
> device's vector at attach time, or NULL if one didn't exist or was
> invalid. The interrupt return assembler code (common to all interrupt
> handlers) uses this return value to jump to the next interrupt handler
> on the chain.
>

[stuff deleted]

------------------------------

Date: Mon, 8 Mar 93 10:08:34 PST
From: [e-mail] (Jack Brindle)
Subject: hidden transmitter routing
To: [e-mail]

>This discussion has got me wondering how to best handle full-duplex
>operation over a path that has a long inherent time-delay relative to
>the typical packet size.  Specifically, suppose we had a high-orbit
>satellite or (I wish) a geostationary satellite with a portion of it's
>up and downlink spectrum dedicated for packet use in full-duplex
>mode.  This would be an ideal repeater at say 1200 BAUD rates.  But when
>you start looking at the quarter second delay between when a ground station
>transmits and when its signal is detectable by other ground stations, it
>seems to me that this inherent delay can cause some serious problems
>at the higher BAUD rates.  This is one situation that doesn't seem to
>get that much better by virtue of having a full-duplex repeater
>available.  Wouldn't this require a fix of a different nature?
>Perhaps some form of token bus?

Actually the VSAT guys already seem to have this one figured out pretty well.
They run transponders with multiple "low-rate" up channels, and a single
high-rate down channel. The up channels typically run about 32kb to 56kb,
while the down channel is around 512kb. The receive side of the satellite
is around a meg or two wide, and can handle many simultaneous uplinks. They
actually do place multiple stations on the same uplink frequency, accepting
the possibility of collisions and handling this with the transport layer. I
don't know if they use any collision avoidance system; maybe someone from
Tridom or one of the other VSAT vendors could comment...

I could see a ham satellite with a similar system, say a dozen or so 1200
baud up channels and a single 56k down channel. The math types would tell
us that the probability of hitting full capacity on the up channels (to
completely fill the down channel) is relatively low, so we could even design
the up channels for higher capacity than the down channel. Buffering in the
satellite would handle the short-lived peak times when the downlink couldn't
keep up.

Interesting...

Jack Brindle
------------------------------------------------------------------------------
ham radio: wa4fib                             internet: [e-mail]

------------------------------

Date: Tue, 9 Mar 93 0:08:49 HST
From: Antonio Querubin <[e-mail]>
Subject: hidden transmitter routing
To: [e-mail] (Jack Brindle)

> >This discussion has got me wondering how to best handle full-duplex
> >operation over a path that has a long inherent time-delay relative to
> >the typical packet size.  Specifically, suppose we had a high-orbit
> >satellite or (I wish) a geostationary satellite with a portion of it's
> >up and downlink spectrum dedicated for packet use in full-duplex
> >mode.  This would be an ideal repeater at say 1200 BAUD rates.  But when
> >you start looking at the quarter second delay between when a ground station
> >transmits and when its signal is detectable by other ground stations, it
> >seems to me that this inherent delay can cause some serious problems
> >at the higher BAUD rates.  This is one situation that doesn't seem to
> >get that much better by virtue of having a full-duplex repeater
> >available.  Wouldn't this require a fix of a different nature?
> >Perhaps some form of token bus?
>
> Actually the VSAT guys already seem to have this one figured out pretty well.
> They run transponders with multiple "low-rate" up channels, and a single
> high-rate down channel. The up channels typically run about 32kb to 56kb,
> while the down channel is around 512kb. The receive side of the satellite
> is around a meg or two wide, and can handle many simultaneous uplinks. They
> actually do place multiple stations on the same uplink frequency, accepting
> the possibility of collisions and handling this with the transport layer. I
> don't know if they use any collision avoidance system; maybe someone from
> Tridom or one of the other VSAT vendors could comment...
>
> I could see a ham satellite with a similar system, say a dozen or so 1200
> baud up channels and a single 56k down channel. The math types would tell
> us that the probability of hitting full capacity on the up channels (to
> completely fill the down channel) is relatively low, so we could even design
> the up channels for higher capacity than the down channel. Buffering in the
> satellite would handle the short-lived peak times when the downlink couldn't
> keep up.

The problem with this approach is that the maximum throughput any one
station sees is limited to 1200 BAUD regardless of the channel usage.
Yet we have satellites that can already do 9600 BAUD.  We ought to be
designing the next generation of packet satellites with the criteria
that they run at LEAST as fast as 9600 BAUD and that the full
bandwidth of the channel be available under the best of conditions.

But suppose we don't have the best of conditions, ie. there are more
than two stations are talking to each other on the same satellite
channel.  And suppose these stations are using the currently available
technology (G3RUH or WA4DSY style modems).  How does one go about
picking the slot-time and p-persistence values to minimize collisions?
Setting the slot-time to a quarter-second seems reasonable at 1200
BAUD, but seems less so at 9.6 or 56 kbps.  Would using a slot-time
equal to the maximum packet length be reasonable?  In this case, I
suppose we'd be accepting a greater chance for collisions in return
for possibly higher throughput under low channel-usage conditions and
the collisions handled by upper layer backoff algorithms.

At 56 kbps, one could even think about doing collision detection
between packet transmissions assuming the maximum packet size is
chosen to never exceed a quarter-second transmission time.  I can see
a modified collision-detecting KISS that doesn't clear a packet from
the transmit queue until it sees the packet echo from the satellite
between transmissions.

More exotic approaches might use some form of token-ring or
time-multiplexing or a combination of the two.  Not exactly sure how
that would work though.  Just thinking out loud folks.  These problems
have been bothering me for a while now and the current thread over
reworking AX.25 caught my attention :-).  Does anyone know of any
papers that seriously analyse high-speed packet over high-orbit
satellite links?

Tony

------------------------------

Date: Mon, 8 Mar 93 13:43:30 GMT
From: [e-mail]
Subject: TCP Window
To: [e-mail]

Apologies if this is old hat, but it's been causing confusion in South-East
England for months.

What was observed was that many stations were putting out TCP frames with
the TCP window parameter = 2048. When asked to add a "tcp window 648" to
their start-up file the reply was often "but I have that there already!".

Anyway, at the weekend I was playing around with the possibility of
different window lengths on different ports (so I can have a TCP window of
5000 or so on my shack Ethernet =without= this window also applying to
the 2 metre radio port... I'd like to remain on friendly terms with the
other users of the freq!).

(Let's ignore whether this is good or bad practice.. it isn't the main point
of this note).

After a while I thought I'd achieved it (by adding a 'ifconfigure <port> window'
command - if set to 0 for a port, use the 'tcp window' setting). And sessions
I created had the appropriate window size. =But= incoming sessions didn't,
they always had the 'tcp window' setting as the window in the ACK SYN frame.

After a bit of thought and reading the code, the tcp window for the ACK SYN
frame must come from the server code and is presumably set when the
'start <server>' command is issued (although I must confess I couldn't find
where the "rcv.wnd" gets set other than in the 'open_tcp' function in TCPUSER -
in JNOS 108).

So I played some more with the original code (i.e. without my window per port
mod), with interesting findings-
if the start-up file has:

tcp window 648
start telnet
start.... (rest of servers)
tcp window 432

Then sessions initiated by me had a TCP window of 432, incoming sessions
ACK SYN'd with a window of 648.

I then played around with a local station who has the "window = 2048" problem
outlined at the start.
And, yes, sessions he initiated had the correct window, his replies to incoming
sessions gave a window of 2048.
A quick peep in his AUTOEXEC.NOS showed that he set 'tcp window' AFTER starting
the servers. Having got him to set the tcp window =before= starting the servers
it's all ok. Obviously it was picking up the DEF_WND value from TCP.H (2048) as
the tcp window wasn't set.

So, the moral is:

set 'tcp window' before starting the servers.


(I'm still uncertain as to whether this is a bug or a feature! I can't really
say I'm totally happy that I've found where the "rcv.wnd" gets set for an
incoming session request, but I presume it is in the open_tcp call when the
server is started. In which case 'tcp window' is bound to give this slightly
inconsistent behaviour.
And for the time being, I've shelved my window per port idea!)


Andrew Benham
--------------------------------------------------------------------
[e-mail]   BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
                 [phone]    Fax: [phone]
Home:            [e-mail] [44.131.19.195]    G8FSL@GB3XP
--------------------------------------------------------------------

------------------------------

Date: Mon, 8 Mar 93 15:21:26 GMT
From: Alan Cox <[e-mail]>
Subject: TCP Window
To: [e-mail], [e-mail]

What would be more useful is a 2K or so netrom tcp window and a smaller
AX.25 window setting. I've sort of nailed it into the KA(Q net for unix I use
Nail being the correct description - the tcp socket setup has a look at the routing
and diddles the window setting.

Alan

------------------------------

End of TCP-Group Digest V93 #65
******************************
******************************